Tidy first? A personal exercise in empirical software design

Kent Beck이 계획하고 있는 소프트웨어 디자인 시리즈 중 첫번째 책. Larry Constantine과 Edward Yourdon의 책 “Structured design”에 영향을 받음.

때론 먼저 치우고 때론 나중에 치움으로써 프로그래밍 경험을 개선하기, 작고 안전한 단계들을 통해 큰 변화를 만들기, 인간 관계 수행으로써의 소프트웨어 설계 등의 내용을 다룬다.

Foreword

Preface

이 책의 주제

”Tidy First?” describes:

• When to tidy messy code before changing what it computes
• How to tidy messy code safely and efficiently
• How to stop tidying messy code
• Why tidying works

소프트웨어 설계의 양면성:

Software design is a powerful tool to ease pain in the world - if it is used well. Used badly, it becomes just another instrument of oppression, and a drag on the effectiveness of software development.

Empirical software design

Introduction

많은 사람들이 기능 개선 없이 설계 변경만 오래하는 걸 리팩토링으로 착각. 시스템의 동작을 바꿔선 안된다는 조건도 까먹음. 그 결과, 리팩토링을 하면 아무 기능 추가 없이 시간만 오래 쓰고 그 결과로 시스템이 종종 깨지곤 한다는 오해가 생김.

지난 20년 간 ‘리팩토링을 하려면 경영진을 설득해야 하는데…’으로 시작하는 사연을 종종 들어왔는데, 대부분의 리팩토링은 그냥 하면 된다. 리팩토링 책 서문은 기능 추가를 멈추고 설계만 개선하다가 망한 사례로 시작한다. 대안으로 기능 추가를 하면서 동시에 설계를 조금씩 개선하는 기법으로 ‘리팩토링’을 소개한다.

몇 달에서 몇 년 동안 하는 리팩토링도 있겠으나(초판본 12장 “Big Refactorings”의 주제), 이 경우에도 경영진 설득하느라 고생하지 말고 기능 추가를 하면서 매일 조금씩 하라고 조언한다. “실제 작업에 꼭 필요한 만큼의 리팩토링만 해라. 내일 언제든 다시 이어서 할 수 있다.”

아무튼, 이런 오해들로 인해 새 단어(tidying)를 도입해야할 필요성을 더 크게 느꼈을 수도 있겠다.

Part I. Tidyings

1부에서는 15개의 “tidyings”를 소개하는데 매우 작은 리팩토링 같은 느낌이다. 디자인 패턴의 마이크로 버전이 1997년 저서 Smalltalk Best Practice Patterns라면, 리팩토링의 마이크로 버전이 tidyings라고 보면 되겠다.

• Guard clauses
• Dead code
• Normalize symmetries
• New interface, old implementation
• Reading order
• Cohesion order
• Move declaration and initialization together
• Explaining variables
• Explaining constants
• Explicit parameters
• Chunk statements
• Extract helper
• One pile
• Explaining comments
• Delete redundant comments

Part II. Managing

• Separate tidying
• Chaining
• Batch Sizes
• Rhythm
• Getting Untangled
• First, After, Later, Never

Part III. Theory

옵션optionality, 현금흐름, NPV 등. Extreme programming explained의 “변화를 수용하라embrace change”, Lean software development의 “옵션 기반 사고options thinking”, Software by numbers의 Incremental funding method 등과 통하는 내용.

• “지금까지 뭘 구현했나?” 뿐 아니라 “다음에 뭘 구현할 수 있는 가능성들이 열려있나?”도 가치있다. 구현되지 않았더라도 가능성 그 자체가 독립적인 가치이다. 불확실성이 클수록 옵션의 가치는 커진다.
• 가능하면 많은 설계를 가역적reversible인 상태로 유지하기 또는 비가역적 설계를 가역적 설계로 바꾸기. Lean software development에서 말하는 “비가역적 의사결정을 최대한 미루기” 등과 연결됨.

Chapter 22. Beneficially Relating Elements

2009년에 소개했던 Design is beneficially relating elements의 내용을 다시 소개:

• 설계의 결과물은? 서로 이롭게 연결된 요소들 (the design is beneficially relating elements)
• 설계를 한다는건? 요소들을 서로 이롭게 연결하기 (designers are beneficially relating elements)

Chapter 23. Structure and Behavior

Chapter 24. Economics: Time Value and Optionality

Chapter 25. A Dollar Today > A Dollar Tomorrow

Chapter 26. Options

Chapter 27. Options Versus Cash Flows

Chapter 28. Reversible Structure Changes

Chapter 29. Coupling

Chapter 30. Constantine’s Equivalence

Constantine’s equivalence

Chapter 31. Coupling Versus Decoupling

Chapter 32. Cohesion

Chapter 33. Conclusion

그래서 언제 치울까?

• 비용이 줄거나, 미뤄지거나, 가능성이 낮아지는지
• 이득이 커지거나, 당겨지거나, 가능성이 높아지는지
• 결합은 낮아지고 응집은 높아지는지
• 제일 중요한건 당신에게 안정/즐거움/만족감을 주는지

대체로 먼저 치우기. 적당히만.

Appendix. Annotated Reading List and References

짧은 독후감

재미있게 읽었다. 1부에 열거된 tidying들이 기술적인 관점에서만 보면 너무나 작고 사소해서(예: “빈 줄을 넣어라”) 별 내용 없는 책으로 여겨질 가능성이 있어 보인다. 사실 작고 사소하기 때문에 가치가 있는건데.

1부는 자칫 “초보자”들에게나 적합한 내용 정도로 치부될 가능성이 있는 반면, 3부에서 소개하는 이론들은 상당한 경험을 쌓은 후에야 공감할 수 있는 내용들이 아닌가 싶다.

저자가 서문에서 본인이 Larry Constantine의 책을 처음 읽을 당시엔 내용을 거의 이해하지 못했다가 오랜 세월이 지나고서야 진가를 알게 되었고 “Tidy First?”에서 L.C.의 책에 담긴 내용을 본인이 재해석하여 소개하고자 한다고 썼는데, 그래서인지 이 책의 3부도 경험을 필요로하는 내용들인 것 같다.

국내외를 막론하고 패턴 책에서는 패턴 카탈로그만 읽고 리팩토링 책에서는 코드 냄새 목록만 읽는 식으로 쉽게 요약해서 소비할만한 내용 위주로 읽고 공유하는 경향이 있는 것 같다. 이 책도 그런 식으로 읽는다면 1부의 작고 사소한 tidying 목록 15개만 돌아다니게 될 가능성이 있어 보인다.

만약 그렇게 된다면 ‘완전 초보를 위한 코딩 팁 15개를 담은 책’ 정도로 여겨질 수도 있겠다.

아무튼, 오래 마음 속에 담아두고 기획한 연작의 첫번째 결과물이라고 하는데 나는 아주 재미있게 읽었고 이 시리즈의 다음 책이 기대된다.

ToDo: 이 타레 옮기기